In network communications, especially communications over a wide area network (“WAN”) such as the Internet, it is often important to secure the communicated messages. As there are many possibilities for intercepting, eavesdropping, or tampering by third parties, many such communicated messages should be secured.
A known approach for securing communication is the internet protocol security (“IPsec”), which is a suite of related protocols for cryptographically securing communications at the IP Packet Layer. The IPsec provides confidentiality, data integrity, access control, and data source authentication of IP datagrams being sent over various communication channels. These services are provided by maintaining shared secrets between the source and the sink of an IP datagram. IPsec includes protocols for establishing mutual authentication between participants at the beginning of the session, and negotiation of cryptographic keys to be used during the session.
The Internet Key Exchange (“IKE”) protocol is a component of IPsec used for performing mutual authentication and establishing and maintaining IPsec security associations (“SAs”). A SA is a unidirectional agreement between participants regarding the methods and parameters to use in securing a communication channel (e.g., establishing a virtual private network (“VPN”)). A SA is a bundle of algorithms and parameters (such as keys) that are being used to encrypt and authenticate a particular communication flow in one direction. Full bidirectional communication requires at least two SAs, one for each direction. An IPsec tunnel includes a pair of unidirectional SAs—one SA for each direction of the tunnel—that specify the security parameter index (“SPI”), destination IP address, and security protocol (Authentication Header (“AH”) or Encapsulating Security Payload (“ESP”)) employed. Further information on IPsec and the attributes for SA and IKE negotiations can be found in RFC 4306, which is a published document hereby incorporated by reference herein.
The Internet Key Exchange Version 2 (“IKEv2”) protocol dynamically establishes and maintains a shared state (for a secure communication channel) between the end-points of an IP datagram. IKEv2 negotiates the IKEv2 Security Association (“IKE-SA”) for establishing a secure communication channel over a network between participants. The IKE_SA uses shared secret information that it stores to do two different functions (1) establish CHILD_SAs for ESP Protocol and/or AH Protocol, and (2) defines the cryptographic algorithms to be used by the SAs. The IKEv2 protocol is described in detail in RFC 7296—Internet Key Exchange Protocol Version 2 (IKEv2), published October 2014, which is hereby incorporated by reference herein (hereinafter referred to as “RFC 7296”).
Referring to FIG. 1, in order to negotiate and establish an IKE_SA, a basic IKEv2 exchange in accordance with the prior art is performed between the participants, often identified as the Initiator 101 and the Responder 102. The basic IKEv2 protocol is a request/response pair protocol that contains four messages (or two exchanges). The first exchange contains an IKE_SA_INIT request message from the initiator 101 to the Responder 102, and an IKE_SA_INIT response message from the Responder 102 to the initiator 101. These messages are “plain,” meaning that they are non-encrypted and non-authenticated messages. This first exchange (first pair) of messages negotiates cryptographic algorithms, exchange notices, and does a Diffie-Hellman exchange between the two participants desiring to establish an IKE SA.
Within this disclosure, a “Plain IKE_SA_INIT Request Message” is defined as a non-encrypted and non-authenticated IKE_SA_INIT request message, such as disclosed in the previously referenced RFC 7296. Within this disclosure, a “Plain IKE_SA_INIT Response Message” is defined as a non-encrypted and non-authenticated IKE_SA_INIT response message, such as disclosed in the previously referenced RFC 7296.
The second exchange (second pair) of messages contains an IKE_SA_AUTH request message from the Initiator 101 to the Responder 102, and an IKE_SA_AUTH response message from the Responder 102 to the Initiator 101. This second pair of messages exchanges identities and certificates, and establishes further communication. Parts of these second pair of messages are protected with keys established through the first pair of messages. At the end of the IKE_AUTH exchanges, the participants (e.g., the Initiator 101 and the Responder 102) have successfully established a secure communication channel over a network (e.g., a VPN).
A problem with the foregoing is that the prior art IKE_SA_INIT exchange uses the previously noted Plain messages (i.e., the non-encrypted and non-authenticated Plain IKE_SA_INIT Request Message and Plain IKE_SA_INIT Response Message). These Plain messages can lead to one or more types of attacks from third parties, such as man-in-the-middle, denial-of-service (“DoS”), and spoofing attacks.